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(57) Abstract 

A device has processing hardware to carry out a 
blood processing procedure. A processing control man- 
ager resides on the device to monitor status conditions 
over time during the blood processing procedure. A 
data interface also resides on the device. The data in- 
terface includes a flash memory data storage medium 
formatted to allocate discrete block file spaces to retrieve 
data. Chronologic data or time-specific data are created 
based upon sensed conditions by a data generator task, 
which also resides on the device. A file manager task 
appends chronologic data to an allocated file space to 
create a chronologic block file, which, when read, pro- 
vides a time-ordered account of processing activities or 
hardware conditions. The file manager also operates to 
block-write time-specific data to another allocated file 
space, which, when read, creates a snap-shot of pro- 
cessing conditions at a given point in time. The data , 8 _ 
file structure created on the flash memory medium with- 
stands corruption of data due to power failure. 
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SYSTEMS AND METHODS FOR STORING , RETRIEVING, 
AND MANIPULATING DATA IN MEDICAL 
PROCESSING DEVICES 
FIELD OF THE INVENTION 

5 The invention relates to systems and 

methods for recording data during the course of 
fluid processing procedures, such as those carried 
out by blood processing systems and the like* 
BACKGROUND OF THE INVENTION 
10 Today people routinely separate whole blood 

by centrifugation into its various therapeutic 
components, such as red blood cells, platelets, and 
plasma. 

These and other medical processing devices 
15 are often controlled using microprocessors with 
resident program software. The microprocessors also 
usually include some type of interface through which 
the operator views and comprehends information 
regarding the operation of the fluid processing 
20 systems. 

These and other medical processing devices 
also often require the ability to record key control 
and processing parameters during the course of a 
procedure, as well as to keep track of operator 

25 intervention during the procedure. These data 
recording functions are useful, as they support, 
e.g., GMP requirements, instrument trouble shooting 
and problem diagnosis, and instrument performance 
evaluation. Still, while important, data recording 

30 functions should not compete or interfere with the 
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overall processing tasks and objectives of the 
procedure. 

As the operational and performance demands 
upon such fluid processing systems become more 
complex and sophisticated, the need exists for 
integrating, automating, and fortifying data 
recording functions. 

SUMMARY OF THE INVENT TON 

The invention provides systems and methods, 
which fully integrate data recording functions with 
processing functions. Thus, the same instrument 
that carries out the processing tasks also performs 
the data recording functions, without the need for 
add-on, external data recording systems. 

The invention also provides systems and 
methods, which fully automate necessary data 
recording functions, so that they can be 
accomplished "in the background," without 
significant operator intervention or control. 

The invention also provides robust systems 
and methods, which carry out data recording 
functions that withstand real world abuse, such as 
power failure or corruption of stored data. This 
"crash-proof" aspect is particularly significant in 
an embedded software systems environment, where an 
instrument may be powered off at any time. 

One aspect of the invention provides 
systems and methods for processing data during a 
blood processing procedure. The systems and methods 
monitor status conditions over time during the blood 
processing procedure and generate data based upon 
monitored status conditions. The systems and 
methods write the data to a flash memory storage 
medium. In a preferred embodiment, the systems and 
methods retrieve and manipulate the data written to 
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the flash memory storage medium. 

The use of flash memory provides 
reliability and compact size, so that robust data 
storage, retrieval, and processing functions can be 
5 carried out on-board a blood processing device, 
without need for external computing devices and 
without concern about the durability and reliability 
of the data storage functions. 

According to another aspect of the 

10 invention, blood processing systems and methods 
employ a device that has processing hardware to 
carry out a blood processing procedure. A 
processing control manager resides on the device to 
monitor status conditions over time during the blood 

15 processing procedure. A data interface also resides 
on the device. The data interface includes a data 
storage medium formatted to allocate discrete block 
file spaces to receive data. 

In a preferred embodiment, chronologic data 

20 or time-specific data can be created, based upon 
sensed conditions by a file generator task, which 
resides on the device. A file manager task operates 
to append chronologic data in an allocated file 
space to create a chronologic block file. When 

25 read, the chronologic block file provides a time- 
ordered account of processing activities or hardware 
conditions. The file management element also 
operates to block-write time-specific data to 
another allocated file space. When read, each time- 

30 specific data file provides a snap-shot of 
processing conditions at a given point in time. The 
data file structure created withstands corruption of 
data due to power failure. 

The features and advantages of the inven- 

35 tion will become apparent from the following de- 
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scription, the drawings, and the claims. 
BRIEF DESCR IPTION OP THE DRAWTKflfl 

Fig. 1 is a diagrammatic view of a dual 
needle platelet collection system that includes a 
5 controller that embodies the features of the 
invention; 

Fig, 2 is a diagrammatic flow chart view of 
the controller and the associated instrument manager 
and graphical user interface; 
10 Fig. 3 is another diagrammatic view of the 

controller and the associated instrument manager and 
graphical user interface shown in Fig. 2, and 
further showing the command and status flow 
hierarchy; 

15 Fig. 4 is a view of the dual region 

graphical user interface screen, showing the block 
and touch activated fields that the interface screen 
contains, and also showing the Main Menu in the 
working region of the interface screen; 
20 Fig. 5 a view of the dual region interface 

screen, showing the Select Procedures Submenu in the 
working region of the interface screen; 

Fig. 6A a view of the dual region interface 
screen, showing the Special Features Submenu in the 
25 working region of the interface screen; 

Fig. 6B a view of the dual region interface 
screen, showing the File Manger Submenu in the 
working region of the interface screen; 

Fig. 7 is a diagrammatic flow chart view of 
30 the controller and the associated data interface; 

Fig. 8 is a diagrammatic view of the block 
file structure of the storage device of the data 
interface shown in Fig. 7; 

Fig. 9 is a diagrammatic view of the 
35 directory table of the block file structure shown in 
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Fig . 8 ; 

Fig. 10 is a diagrammatic view of one block 
file space allocated in the block file structure 
shown in Fig. 8; 
5 Fig. 11 is a diagrammatic view of the 

ringfile function, which controls the writing of 
data into the block file space shown in Fig. 10; 

Fig. 12 a view of the dual region interface 
screen, showing the File System Information Submenu 
10 in the working region of the interface screen; 

Fig. 13 a view of the dual region interface 
screen, showing the File Directory Submenu in the 
working region of the interface screen; 

Fig. 14 is a representative Procedure 
15 Report that the data interface shown in Fig. 7 can 
generate; 

Fig. 15 is a representative Event Report 
that the data interface shown in Fig. 7 can 
generate; 

20 Fig. 16 a view of the dual region interface 

screen, showing the Print Procedure Reports Submenu 
in the working region of the interface screen; 

Fig. 17 a view of the dual region interface 
screen, showing the Log Viewer Submenu in the 
25 working region of the interface screen; 

Fig. 18 a view of the dual region interface 
screen, showing the System Configuration Submenu in 
the working region of the interface screen; 

Fig. 19 a view of the dual region interface 
30 screen, showing the Set Configuration Submenu in the 
working region of the interface screen; 

Fig. 20 is a schematic view of the 
predictor function of the data interface; and 

Fig. 21 is a schematic view of the import 
35 configuration function of the data interface. 
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The invention may be embodied in several 
forms without departing from its spirit or. essential 
characteristics. The scope of the invention is 
defined in the appended claims, rather than in the 
5 specific description preceding them. All embodi- 
ments that fall within the meaning and range of 
equivalency of the claims are therefore intended to 
be embraced by the claims. 

DESCRIPTION OF THE PRE FERRED EMBODIMENTS 

10 Fig. l shows in diagrammatic form a fluid 

processing system 10. The system 10 can be used for 
processing various fluids. The system 10 is 
particularly well suited for processing fluids for 
medical purposes, like whole blood and other suspen- 

15 sions of biological cellular materials. Accordingly, 
the illustrated embodiment shows the system 10 used 
for this purpose. 

I. THE SEPAR ATION SYSTEM 

The system 10 includes an arrangement of durable 
20 hardware elements. The hardware elements will vary 
according to the nature and type of processing 
system. In the context of processing whole blood, 
the hardware elements will include a centrifuge 12, 
in which whole blood (WB) is separated into its 
25 various therapeutic components, like platelets, 
plasma, and red blood cells (RBC) . The hardware 
elements will also include various pumps, which are 
typically peristaltic (designated PI to P4) ; and 
various in line clamps and valves (designated VI to 
30 V3). Of course, other types of hardware elements 
will typically be present, which Fig. l does not 
show, like solenoids, pressure monitors, and the 
like. 

The system 10 typically also includes some form 
35 of a disposable fluid processing assembly 14 used in 


association with the hardware elements. 

In the illustrated blood processing system 10, 
the assembly 14 includes a two stage processing 
chamber 16, In use, the centrifuge 12 rotates the 
processing chamber 16 to centrif ugally separate 
blood components. 

The construction of the two stage processing 
chamber 16 can vary/ For example, it can take the 
form of double bags, like the processing chambers 
shown in Cullis et al. U.S. Patent 4,146,172. 
Alternatively, the processing chamber 16 can take 
the form of an elongated two stage integral bag, 
like that shown in Brown U.S. Patent 5,370,802. 

In the illustrated blood processing system 10, 
the processing assembly 14 also includes an array of 
flexible tubing that forms a fluid circuit. The 
fluid circuit conveys liquids to and from the 
processing chamber 16. The pumps P1-P4 and the 
valves V1-V3 engage the tubing to govern the fluid 
flow in prescribed ways. The fluid circuit further 
includes a number of containers (designated CI to 
C3) to dispense and receive liquids during process- 
ing. 

A controller 18 governs the operation of the 
various hardware elements to carry out one or more 
processing tasks using the assembly 14. The 
invention specifically concerns important attributes 
of the controller 18. 

The system 10 can be configured to accomplish 
diverse types of blood separation processes. Fig. 1 
shows the system 10 configured to carry out an 
automated two needle platelet collection procedure. 

In a collection mode, a first tubing branch 20 
and the whole blood inlet pump P2 direct WB from a 
draw needle 22 into the first stage 24 of the 


processing chamber 16. Meanwhile, an auxiliary 
tubing branch 26 meters anticoagulant from the 
container CI to the WB flow through the antico- 
agulant pump Pi, 

The container C2 holds saline solution. Another 
auxiliary tubing branch 28 conveys the saline into 
the first tubing branch 20, via the in line valve 
VI , for use in priming and purging air from the 
system 10 before processing begins. Saline solution 
is also introduced again after processing ends to 
flush residual components from the assembly 14 for 
return to the donor. 

Anticoagulated WB enters and fills the first 
stage 24 of the processing chamber 24. There, 
centrifugal forces generated during rotation of the 
centrifuge 12 separate WB into red blood cells (RBC) 
and platelet-rich plasma (PRP) . 

The PRP pump P4 operates to draw PRP from the 
first stage 24 of the processing chamber 16 into a 
second tubing branch 30 for transport to the second 
stage 32 of the processing chamber 16. There, the 
PRP is separated into platelet concentrate (PC) and 
platelet-poor plasma (PPP) . 

The system 10 includes a recirculation tubing 
branch 34 and an associated recirculation pump P3. 
The processing controller 18 operates the pump P3 to 
divert a portion of the PRP exiting the first stage 
24 of the processing chamber 16 for remixing with 
the WB entering the first stage 24 of the processing 
chamber 16. 

As WB is drawn into the first chamber stage 24 
for separation, the illustrated two needle system 
simultaneously returns RBC from the first chamber 
stage 24, along with a portion of the PPP from the 
second chamber stage 32, to the donor through a 


return needle 36 through tubing branches 38 and 40 
and in line valve V2. 

The system 10 also collects PC in some of the 
containers C3 through tubing branches 38 and 42 and 
in line valve V3 for storage and therapeutic use. 
The system 10 can also collect PPP in some of the 
containers C3 through the same fluid path. 

IX. THE SYSTEM CONTROLLER 

The controller 18 carries out the overall 
process control and monitoring functions for the 
system 10 as just described. 

In the illustrated and preferred embodiment (see 
Fig. 2), the controller comprises a main processing 
unit (MPU) 44. In the preferred embodiment, the MPU 
44 comprises a type 68030 microprocessor made by 
Motorola Corporation, although other types of 
conventional microprocessors can be used. 

In the preferred embodiment, the MPU 44 employs 
conventional real time multi-tasking to allocate MPU 
cycles to processing tasks. A periodic timer 
interrupt (for example, every 5 milliseconds) 
preempts the executing task and schedules another 
that is in a ready state for execution. If a 
reschedule is requested, the highest priority task 
in the ready state is scheduled. Otherwise, the 
next task on the list in the ready state is 
schedule. 

A. Functional Hardware Control 

The MPU 44 includes an application control 
manager 46. The application control manager 46 
administers the activation of a library 48 of 
control applications (designated Al to A3). Each 
control application A1-A3 prescribes procedures for 
carrying out given functional tasks using the system 
hardware (e.g., the centrifuge 12, the pumps P1-P4, 
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and the valves V1-V3) in a predetermined way. In the 
illustrated and preferred embodiment, the applica- 
tions A1-A3 reside as process software in EPROM's in 
the MPU 44. 

The number of applications A1-A3 can vary. In 
the illustrated and preferred embodiment, the 
library 48 includes at least one clinical procedure 
application Al. The procedure application Al 
contains the steps to carry out one prescribed 
clinical processing procedure. For the sake of 
example in the illustrated embodiment, the library 
48 includes a procedure application Al for carrying 
out the dual needle platelet collection process, as 
already generally described in connection with Fig. 
1. Of course, additional procedure applications can 
be, and typically will be, included. For example, 
the library 48 can include a procedure application 
for carrying out a conventional single needle 
platelet collection process (Al 1 ) . 

In the illustrated and preferred embodiment, the 
library 48 also includes at least one additional, 
non-procedure application. The non-clinical 

procedural application contains the procedures to 
carry out a system configuration or support utility. 
For the sake of example in the illustrated 
embodiment, the library 48 includes a configuration 
application A2, which contains the procedures for 
allowing the operator to configure the default 
operating parameters of the system 10. The library 
48 also includes a main menu application A3, which 
coordinates the selection of the various applica- 
tions A1-A3 by the operator, as will also be 
described in greater detail later. 

Of course, additional non-clinical procedure 
applications can be, and typically will be, 


included. For example, the library 48 can include 
a diagnosis application, which contains the 
procedures aiding service personnel in diagnosing 
and troubleshooting the functional integrity of the 
system, and a system restart application, which 
performs a full restart of the system, should the 
system become unable to manage or recover from an 
error condition. 

An instrument manager 50 also resides as process 
software in EPROM's in the MPU 44. The instrument 
manager 50 communicates with the application control 
manager 46. The instrument manager 50 also 
communicates with low level peripheral controllers 
52 for the pumps, solenoids, valves, and other 
functional hardware of the system. 

As Fig. 3 shows, the application control manager 
46 sends specified Perform_Function# commands in 
abstract form to the instrument manager 50, as 
called up by the activated application A1-A3. In 
response to these abstract commands, the instrument 
manager 50 identifies the peripheral controller or 
controllers 52 for performing the function and 
compiles hardware-specific Operate_Hardware# 
commands into the command tables for the particular 
peripheral controllers 52. The peripheral control- 
lers 52 communicate directly with the hardware to 
implement the hardware-specific commands generated 
by the instrument manager 50, causing the hardware 
to operate in a specified way to carry out the 
abstract Perform_Function# commands. A communication 
manager 54 manages low-level protocol and communica- 
tions between the instrument manager 50 and the 
peripheral controllers 52. 

As Fig. 3 also shows, the instrument manager 50 
also conveys back to the application control manager 
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46 status data about the operational and functional 
conditions of the processing procedure. The status 
data is expressed in terms of, for example , fluid 
flow rates, sensed pressures, and fluid volumes 
5 measured. 

The application control manager 46 processes and 
uses the status data in various ways* In one way, 
the application control manager 46 transmits 
selected status data for display to the operator, as 

10 will be described later. In another way, the 
application control manager 4 6 monitors operational 
and functional conditions using the status data to 
detect abnormal system conditions requiring operator 
intervention or system shutdown. 

15 In the preferred embodiment (see Fig. 2), the 

MPU 44 also includes a condition manager 56 that 
resides in the data flow path between the instrument 
manager 50 and the communications manager 54. The 
condition manager 56 also monitors status data and 

20 other operational states of the hardware to detect 
abnormal conditions that are either not detected or 
are left uncorrected by the application control 
manager 46. Upon detecting such abnormal conditions, 
the condition manager 56 provides fail-safe support 

25 by suspending system operation. 

The described control hierarchy creates an ab- 
stract, "virtual" interface between the applications 
resident in the application control manager 46 and 
the hardware elements of the system 10. The high 

30 level process software resident in the application 
control manager 46 communicates with lower level 
implementing process ^software in the instrument 
manager 50, instead of communicating directly with 
hardware elements. In this way, the intermediate 

35 instrument manager 50 isolates or "hides" all 


hardware-specific commands from the application 
control manager 46. The applications pass abstract 
Perform_Function# commands to the instrument manager 
50, and the instrument manager 50 converts these 
abstract commands into the specific Oper- 
ate_Hardware# commands unique to the particular 
hardware elements, all without further participation 
by the procedure applications A1-A3 themselves. The 
data flow between the instrument manager 50 and the 
hardware elements of the system 10 is invisible to 
the activated application A1-A3. 

The creation of the virtual interface between 
high level process software and the hardware 
elements provides considerable flexibility in adding 
or modifying the process software of the high level 
applications A1-A3 for controlling hardware 
functions. New or modified process software for the 
applications need only to include specified 
hardware-non-specific abstract Perf orm_Function# 
commands to gain immediate linkage to the virtual 
hardware interface. Likewise, addition or 

modification of specific hardware requires only 
changes to the low level process software of the 
instrument manager 50. Because of the virtual 
interface, hardware changes require minimal changes 
to the high level software in the application 
control manager 46. 

As described above, the instrument manager 50 
forms a part of the same KPU in which the 
application control manager 46 resides. Alterna- 
tively, because of the virtual nature of the 
interface, the instrument manager 50 can reside on 
a separate processing unit. 

B. User interface Control 

In the illustrated embodiment, the MPU 44 also 
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includes an interactive user interface 58. The 
interface 58 allows the operator to view and 
comprehend information regarding the operation of 
the system 10. The interface 58 also allows the 
5 operator to select applications residing in the 
application control manager 46, as well as to change 
certain functions and performance criteria of the 
system 10. 

The interface 58 includes ah interface screen 60 

10 and, preferably, an audio device 62. The interface 
screen 60 displays information for viewing by the 
operator in alpha-numeric format and as graphical 
images. The audio device 62 provides audible 
prompts either to gain the operator's attention or 

15 to acknowledge operator actions. 

In the illustrated and preferred embodiment, the 
interface screen 60 also serves as an input device. 
It receives input from the operator by conventional 
touch activation, as will be described later. 

20 Alternatively or in combination with touch 
activation, a mouse or keyboard could be used as 
input devices. 

An interface controller 64 communicates with the 
interface screen 60 and audio device 62. The inter- 

25 face controller 64, in turn, communicates with an 
interface manager 66, which in turn communicates 
with the application control manager 46. The 
interface controller 64 and the interface manager 66 
reside as process software in EPROM's in the MPU 44. 

30 In use, the application control manager 46 sends 

to the interface manager 66 specified field values 
reflecting selected status data received from the 
instrument manager 50. The application control 
manager 46 also sends to the interface manager 66 

35 prescribed abstract Create_Display# and 


Create_Audio# commands called for by the activated 
application. 

The interface manager 66 processes these field 
values and the abstract Create_Display# commands to 
generate specific Format_Display# commands. The 
Format_Display# commands control the particular 
format, attributes, and protocols necessary to 
create, refresh, and close the visual display on the 
interface screen 60. 

Likewise, the interface manager 66 processes the 
abstract Create_Audio# commands to generate specific 
Format_Audio# commands. The Format_Audio# commands 
dictate the format and attributes of the audio 
output called for by the activated application. 

The interface manager 66 conveys the processed 
Format_Display# and _Audio# commands to the 
interface controller 64. The interface controller 
64 provides low level control functions that draw 
boxes and lines, forms text or graphical characters, 
and provides the formatting ant attributes of the 
display on the interface screen 60. The interface 
controller 64 also provides low level control 
functions that drive the audio device 62 based upon 
Format_Audio# commands received from the interface 
manager 66. 

The interface controller 64 also accepts 
Field#_Select commands generated by touch activation 
of the interface screen 60, as will be described in 
greater detail later. The interface controller 64 
passes this touch activated input to the interface 
manager 66 in the form of Touch#_Codes . The 
interface manager 66 processes the Touch#_Codes to 
the application control manager 46, either as 
function codes or as changed field values. The 
application control manager 46 implements the 
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function codes or changed field values and passes 
them to the instrument manager 50. 

This control hierarchy also creates an abstract, 
"virtual" interface between the functional 
processors of the controller 18 and the interface 
58. The high process software of the interface 
manager 66 isolates and "hides" all formatting and 
protocol issues used in creating the interface 58 
from the applications used to control hardware func- 
tions of the system 10. The process software of the 
applications A1-A3, through the application control 
manager 46, pass abstract field values and Cre- 
ate_Display# and Create_Audio# commands to the 
interface manager 66. The process software of the 
interface manager 66 converts these abstract 
commands into the specific commands that control the 
textual and graphic formats and audio formats of the 
operator interface 58, without further participation 
by the procedure applications A1-A3 themselves. The 
data flow between the interface manager 66 and the 
interface controller 64 is invisible to the data 
flow between the application control manager 46 and 
the instrument manager 50. 

This control hierarchy lends further flexibility 
in adding or modifying applications for controlling 
hardware functions. New or modified applications 
need only to include textual field value outputs and 
the prescribed Create_Display# or Create_Audio# 
commands to gain immediate linkage to the operator 
interface. 

(I) Interface Screen Format 
In the illustrated and preferred embodiment (see 
Pig. 4) # the Format_Display# commands of the inter- 
face manager 66 formats information for display on 
the interface screen 60 in two distinct viewing 


regions, called the status region 68 and the working 
region 70. Preferably, the two viewing regions 68 
and 70 are fixed in relative position and unchanging 
in size on the interface screen 60. This provides 
continuity and consistency to the appearance of the 
interface 58, even as the functional hardware of the 
system cycle through different processing modes. 
The uniformity and consistency of the dual viewing 
regions 68 and 70 of the interface 58 reduce 
operator confusion and the likelihood of error. 

The status region 68 and the working region 70 
are each dedicated to different types and levels of 
information. Nevertheless, the two regions 68 and 
70 are always displayed simultaneously to provide 
the operator views of both high level "big picture" 
information and low level "detailed" information. 

The working region 70 provides the means for the 
operator to select and activate any one of the 
system-resident applications A1-A3. The working 
region 70 displays all specific procedure-dependent 
information then called for by the Create_Display# 
commands generated by the activated application Al- 
A3. The considerable detail of information 
displayed in the working region 70 allows the 
operator to monitor and change the ongoing process 
in real time. 

On the other hand, the status region 68 continu- 
ously shows prescribed procedure-dependent 
information of a more general and "overview" nature, 
about which a operator routinely needs continuous 
knowledge and immediate access. The status region 
68 continuously displays this general information to 
keep the operator appraised of the overall status of 
the ongoing process, even when the operator is using 
the working region 70 to monitor and change more 
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detailed aspects of the processes. In the 
illustrated and preferred embodiment, the status 
region 68 also provides means for the operator to 
respond to alarms or malfunctions. 

The two viewing regions 68 and 70 allow the 
operator to use the interface 58 quickly to find and 
select among detailed procedures, functions, and 
options during system operation, or to perform off- 
line functions, without losing touch with the 
overall status of the ongoing procedure. The two 
viewing regions 68 and 70 permit the operator to 
navigate what is in reality a multiple-level menu 
structure to attend to details on one menu level, 
without necessarily moving in steps up and down the 
menu structure and without losing the ability to, on 
command, immediately jump between higher and lower 
menu levels. 

In the illustrated embodiment, the viewing 
regions 68 and 70 are vertically separated by a 
graphical line or line of characters 72, with the 
status region 68 occupying the upper one-third of 
the screen 60 and the working region 70 occupying 
the lower two-thirds of the screen 60. It should be 
appreciated, however, that the viewing regions 68 
and 70 could be separated horizontally in a side by 
side relationship, and occupy differing proportions 
of the screen 60. 

The status region 68 and the working region 70 
display information in fields. The Format_Display# 
for the particular display that the interface 
manager 66 generates is composed of a list of such 
fields specifying, for each field, its location, 
size, and type in the region and the format of 
information it contains. 

As will be discussed in greater detail later, 
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the fields can formatted as individual touch 
selectable buttons. The fields can also be 
formatted as an array of touch selectable button 
fields, which present a field of choices to the 
5 operator. 

The fields can also be formatted as blocks 
comprising alpha or numeric data strings, or textual 
data comprising multiple lines of line-wrapped, 
scrollable text, or graphic images. The fields can 

10 also be formatted to be bar graph fields, which 
display numeric format in graphical form. 

The interface manager 66 includes constant (ROM- 
based) structures in look-up table form that store 
data describing the layout and formatting of all 

15 display attributes, including regions, field type, 
and field location within the regions. The 
interface manager 66 stores dynamic (RAM-based) 
structures that describe the present state of the 
interface display. Upon receiving a given 

20 Create_Display# command from the activated 
application, the interface manager 66 examines the 
ROM-based table structures and the RAM-based status 
structures to create or update the RAM-based status 
structures, as called for by the activated 

25 application. The interface manager 66 includes a 
time-triggered task routine that performs all 
operations required to periodically update screen 60 
and audio outputs. The interface manager 66 sends 
this processed information to the interface 

30 controller 64 for implementation. 

The interface manager 66 also holds a Func- 
tion#_Code associated with each touch selectable 
button field identified by the Touch#_Code received 
from the interface controller 64. The 

35 Function#_Codes are arranged in constant (ROM-based) 
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look-up table form according to region and field 
location within the region, as identified by the 
Touch#_Code. The interface controller 64 registers 
the region and field location when a given button is 
5 touched, passing this information in the form of a 
Touch#_Code to the interface manager 66. The 
interface manager 66 includes a process button 
utility that awaits and asynchronously processes 
this information by examining the ROM-based table 

10 structure and sending the appropriate Function#_Code 
to the application control manager 46 for 
implementation. 

The information and format selected for display 
in the status region 68 and the working region 70 

15 can vary. 

a. The Status Region 
In the illustrated embodiment (see Fig. 4), 
the status region 68 includes a MAJOR MODE field 74, 
which contains the description of the clinical 

20 procedure activated; a MINOR MODE field 76 , which 

contains a one or two word description of the 
procedure status; and a WB PROCESSED field 78, which 
contains the amount of blood drawn from the donor 
through the draw pump P2 during processing, 

25 expressed numerically in units of ml. 

In the illustrated embodiment (Fig. 4) , the 
status region 68 also includes an array of touch 
selectable button fields, labeled, e.g., HELP 80, 
MAIN MENU 82, PROCEDURE DISPLAY 84, and PAUSE/END 

30 86. When touched, each cause the interface manager 
66 to transmit a prescribed function code for 
implementation by the application control manager 
46, without altering the display of information in 
the blocks fields 74/76/78 on the status region 68. 

35 The status region 68 also includes context- 


WO 99/46657 


PCT/US99/03889 


- 21 - 


10 


15 


20 


25 


30 


35 


dependent NOTE/WARNING PROMPT button field 88 that 
occupies a fixed location on the right side, top 
position, of the status region 68 when an alarm or 
warning is active. The NOTE/WARNING PROMPT button 
field 88 is not displayed when an alarm or warning 
is not active. A MUTE button field 90 also occupies 
a fixed location on the left side, top position, of 
the status region 68 when an alarm is active. A 
WARNING/ ALARM block field also occupies a fixed 
location on the center, bottom position, of the 
status region when an alarm is active. 

b. The Working Region 
In the illustrated and preferred embodiment, the 
working region 70 shows by default the Main Menu 
display called for by the main menu application A3. 
The Main Menu display includes an array of touch 
selectable button fields 94 and 96. 

When touched, the CHOOSE PROCEDURE button field 
94 calls up a function that displays a Procedure 
Submenu in the working region 70 (see Fig. 5). The 
Procedure Submenu lists in an array of touch 
selectable button fields 104 and 106 all clinical 
procedure applications administered by the 
application control manager 46, which in the 
illustrated implementation is the Dual Needle 
Procedure Application Al and the Single Needle 
Procedure Application Al' . When touched, a procedure 
application button field calls up a function that 
directs the application control manager 46 to 
activate the associated application. The activated 
application generates its own designated Cre- 
ate_Display# commands, which the interface manager 
66 implements to change the display in the working 
region 70. 

When touched, the SPECIAL FEATURES button field 
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96 calls up a function that displays a Special 
Features Submenu in the working region 70 (see Fig 
6) . The Features Submenu lists in an array of touch 
selectable button fields 200 designated non-clinical 
procedure specific applications administered by the 
application control manager 46. When a given 
special procedures application button is touched 
that application is activated and the display in the 
working region 70 changes in response to the 
Create_Display# commands .of the activated 
application. Further details of certain buttons in 
the fields 200 will be provided later. 

Further details of the controller 18 and the 
graphical user interface manager 66 as described can 
be found in U.S. Patent 5,581,687, which is 
incorporated herein by reference. 

C. The Data Interface 
in the illustrated and preferred embodiment (see 
Fig. 7), the controller 18 also includes a data 
interface 202. The data interface 202 forms self- 
contained, integrated part of the software and 
hardware architecture of the controller 18. The 
data interface 202 automates the collection, 
retention, and manipulation of key control and 
processing parameters and operator steps during a 
given processing application. The data interface 202 
retains the information in a data structure in a 
mass data storage device 204, which also forms an 
integral part of the controller is. The data 
structure of the storage device 204 permits 
information to be stored, retrieved, and manipulated 
in a secure fashion, which is resistant to 
corruption due to unexpected loss of power. The data 
structure of the storage device 204 also permits 
stored information to be retrieved and formatted 


into printed reports . 

While not essential to its operation, the data 
interface 202 can also, if desired, be linked to one 
or more external computers 206 and 206'. The data 
interface 202 can download stored information to the 
computers 206 206' in either a structured or an 
arbitrary order, as will be described in greater 
detail later. 

The data interface 202 can be implemented in 
various ways. In the preferred embodiment, the mass 
storage device 204 comprises a flash memory card, 
e.g., one conforming to the PCMCIA Type II, PC Card 
ATA standard hardware interface. Conventionally, 
the flash memory storage device 204 can support 
storage ranges from 2 to 85 megabytes. In a typical 
implementation, the flash memory storage device 204 
can hold about 8 megabytes of data. 

The flash memory storage device 204 lends itself 
to use with the integrated data interface 202, 
compared to conventional hard drive storage mediums. 
The flash memory device 204 provides ease of 
formatting and fast data access time. The flash 
memory device 204 presents a small compact size, 
which does not compete for space with blood 
processing hardware. The flash memory device 204 
has no mechanical components, and is therefore 
extremely reliable and is not prone to failure 
caused by repeated use. The flash memory device 204 
also is durable, being resistant to vibration and 
other forces that a centrifugal blood processing 
device routinely generates during a blood processing 
procedure. The flash memory device 204 also is easy 
to service and replace on site. 

The data interface 202 also includes additional 
hardware input/output devices 208, 210, 212, and 
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348, which can take the form of, e.g., conventional 
serial RS-232C port links. other input/output 
devices, such as conventional parallel port links 
and one or more or Ethernet™ communication links, 
can be used. 

In the illustrated embodiment (see Fig. 7) , one 
port link 208 communicates with an external a bar 
code scanner 214. A second port 210 communicates 
with one external computer 206, previously 
described. A third port link 212 communicates with 
an external printer 216. A fourth port link 348 
communicates with the other external computer 206*. 

The data interface 202 also includes various 
process software modules 218 to 230 residing in 
EPROM's in the MPU 44. The process software modules 
218 to 230 carry out prescribed data processing 
tasks. 

The number and type of software modules 218 to 
230 can vary, in the illustrated embodiment, one 
module 218 implements a COMMUNICATIONS MANAGER task. 
The COMMUNICATIONS MANAGER task module 218 handles 
lower level data transfers to and from the RS-232C 
port links 208, 210, 212, and 348. The 
COMMUNICATIONS MANAGER task module 218 prevents the 
MPU 44 from transferring data faster than it can be 
transmitted by the respective RS-232C port links 
208, 210, 212, and 348. 

Another module 220 implements a BAR CODE task. 
The BAR CODE task module 220 receives raw ASCII data 
input from the bar code scanner 214, received 
through the bar code scanner port link 208. The BAR 
CODE task module 220 parses the scanned data and 
assembles it into an input compatible with another 
module, called the PROCEDURE DRIVER TASK module 222, 
which will be described in greater detail later. The 
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PROCEDURE DRIVER TASK module 222 also confirms that 
the scanned data has registered the scanned input, 
and, once confirmed, the BAR CODE task module 220 
formats a feedback message output 232, as will be 
5 described later. 

The data interface 202 also includes other core 
processing modules, which implement, respectively, 
a PROCEDURE DRIVER task, a FILE SYSTEM task, a 
REPORT task, a DATA EXCHANGE task, a DATA DUMP task, 
10 and a USER INTERFACE task. The details of these 
tasks will now be described. 

(I) The PROCEDURE DRIVER Task 
The PROCEDURE DRIVER task module 222 receives 
information from the application control manager 46 
15 and the BAR CODE task module 220. The PROCEDURE 
DRIVER task module 222 registers through the 
application control manager 46 designated key 
control and status information relating to the 
procedure then underway, as well as designated key 
control and status information relating to the 
pumps, solenoids, valves, optical detectors, and 
other functional hardware of the system. The 
PROCEDURE DRIVER task module 222 generates data 
containing this registered information, along with 
25 a date stamp to provide a time-based context. The 
data are structured byte streams, which are further 
processed by the FILE SYSTEM task module 224 for 
storage, retrieval, or manipulation. 

The nature and type of the data that the 
30 PROCEDURE DRIVER task module 222 generates can vary. 

a. Procedure Data (the P Data) 
In the illustrated embodiment, the PROCEDURE 
DRIVER task module 222 registers all scanned bar 
code input, which can comprise, e.g., information 
35 identifying the donor, the processing instrument, 
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and disposable components used for processing. The 
PROCEDURE DRIVER task module 222 also registers from 
the application control manager all key processing 
parameter and blood component yield values, as they 
are initialized and as they are updated during the 
course of the procedure. 

The PROCEDURE DRIVER task module 222 also 
registers all processing mode changes as well as all 
warning alarms generated. In the illustrated 
embodiment, the PROCEDURE DRIVER task module 222 
also registers designed special processing events, 
e.g., the start and stop of needle priming, as well 
as the pausing and resumption of a procedure. 

The PROCEDURE DRIVER task module 222 establishes 
and maintains a random access data file, called 
Act_Proc_Data (designated 234 in Fig. 7). The 
contents of Act_Proc_Data file 234 comprise selected 
control and processing parameters. In the 

illustrated embodiment, the Act_Proc_Data file 234 
is a fixed length file, which is formatted as a 
template to hold data in a prescribed order. Active 
procedure data is periodically written (e.g., every 
15 seconds) to designated locations in the template 
of the Act_Proc_Data file 234. 

The current Act_Proc_Data file 234 therefore 
reflects the real time status of significant control 
and processing parameters and data for the procedure 
then underway. The parameters and data retained by 
the ActJ?roc_Data file 234 can include, e.g. , (I) 
donor identification information (e.g., an assigned 
donor I.D. number, donor sex and weight, an assigned 
blood donation I.D. number, and selected blood 
processing procedure) ; (ii) identification of the 
instrument and the disposable components used for 
processing (e.g., by assigned instrument number and 
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disposable kit code, lot number, and expiration 
date); (iii) initial processing parameter values 
derived (e.g., anticoagulant ratio, platelet 
precounts, whole blood hematocrit, whole blood 
volume to be processed, volume of plasma to collect, 
platelet yield, mean platelet volume, storage volume 
of plasma for the platelets collected, volume of 
citrate returned to the donor, etc.); and (iv) then 
active procedure data (e.g., anticoagulant and 
saline used, anticoagulant and saline present in 
product and storage plasma, the collection time of 
the procedure, amount of WB processed, total WB 
drawn, total plasma storage and product plasma 
collected) . 

In the illustrated embodiment, at the end of the 
procedure (and, if desired, periodically during the 
procedure (e.g., every 15 seconds)), the PROCEDURE 
DRIVER task module 222 generates time stamped 
procedure data 236, which, in shorthand, are called 
»P Data" in Fig. 7). The procedure data 236 is a 
snap-shot of the information held in the then- 
current Act_Proc_Data file 234. 

The procedure data 236 is formatted according to 
the template of the Act_Proc_Data file 234. The 
current procedure data 23 6 contains a synopsis of 
key donor data, instrument and disposable data, 
targeted procedure processing values, and actual 
procedure processing values. Fig. 14 exemplifies the 
nature and type of information contained in a 
representative procedure data file 236, in a written 
report format, as will be described later. 

The PROCEDURE DRIVER sends generated procedure 
data 236 to the FILE SYSTEM task module 224, which 
processes the data on the storage device 204 in a 
designated secure file structure for storage, 
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retrieval, and manipulation. Further details of the 
FILE SYSTEM task module 224 will be described later. 

b. Event Data (the E Data) 
During the course of the procedure, the 
5 PROCEDURE DRIVER task module 222 can also generate 
other discrete types of data. For example, in the 
illustrated embodiment (see Fig. 7) , the PROCEDURE 
DRIVER task module 222 periodically generates time 
stamped event data 238, which together build a 
10 chronological record of key processing events. 

Event data 238, which, in shorthand, are called 
"E Data" in Fig. 7, can be generated in response to 
the occurrence of key events, e.g., marking the 
start of the procedure, the installation of 
15 disposable components, the entry of processing 
parameters, priming, the entry of data scanned by 
the bar code scanner 214, alarm conditions and their 
resolution, and the end of the procedure. Other 
event data 238 can also be generated periodically 
20 (e.g., every 15 minutes) to provide then-current 

processing parameters, e.g., the volume of whole 
blood processed, the whole blood flow rate, whole 
blood inlet pump pressure, red blood cell return 
pump pressure. 

25 The PROCEDURE DRIVER task module 222 

communicates event data 238 to the FILE SYSTEM task 
module 224. As will be described in greater detail 
later, the FILE SYSTEM task module 224 incorporates 
the event data 238 into the designated file 

30 structure on the storage device 204. The stored 
system event data 238, when arranged in chronologic 
order by file time stamp, comprise a time-order 
record of significant procedure events and 
conditions. Fig. 15 exemplifies the nature and type 

35 of information contained in a compilation of 
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representative event data files 238 , in a written 
report format, as will be described later. 

c. System Condition Data (the 8 
Data) 

5 In the illustrated embodiment (see Fig. 7), 

during the course of the system operation, system 
tasks also generate time stamped system condition 
data 336 , which, in shorthand, are $$ called M S 
Data" in Fig. 7. The system condition data represent 
10 preselected states, status, or error conditions 
relating to the pumps, solenoids, valves, optical 
detectors, and other functional hardware of the 
system under the control of the instrument manager 
50. 

15 The PROCEDURE DRIVER task module 222 

communicates system condition data 33 6 to the FILE 
SYSTEM task module 224. As will be described in 
greater detail later, the FILE SYSTEM task module 
224 incorporates the system condition data 336 into 

20 the designated file structure on the storage device 
204. The stored system condition data 336 comprise 
time-order records of significant system hardware- 
related conditions during the course of the 
procedure. Fig. 17 exemplifies the nature and type 

25 of information contained in a compilation of 
representative system condition data 336, when 
formatted for viewing by an operator, as will be 
described later. 

d. The Dump Sensor Data (the D 
30 Data) 

In the illustrated embodiment (see Fig. 7), 
periodically during the course of the procedure 
(e.g., every 5 seconds), the PROCEDURE DRIVER task 
module 222 generates discrete time stamped dump 
35 sensor data 350, which, in shorthand, are called "D 
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Data" in Fig. 7. The dump sensor data 350 are 
snapshots of current sensed values recorded by 
condition sensing hardware coupled to the controller 
18 • The condition sensing hardware can monitor, 
5 e.g., inlet and outlet pump pressures, weights of 
blood collection containers, and optical 
transmission values sensed by optical detectors. 

The PROCEDURE DRIVER task module 222 
communicates dump sensor data 350 to the FILE SYSTEM 

10 task module 224. As will be described in greater 
detail later, the FILE SYSTEM task module 224 
incorporates the dump sensor data 350 into the 
designated file structure on the storage device 204. 
The dump sensor data 350 comprise a time-order 

15 record of sensed conditions monitored during the 
course of a given procedure. 

ii. The FILE SYSTEM task 
The FILE SYSTEM task module 224 provides file 
services for the PROCEDURE DRIVER task module 222, 

20 the DATA EXCHANGE task module 228, and the REPORT 

task module 226. It provides the interface for 
storage, retrieval, and manipulation of the 
procedure data 236, the event data 236, the system 
condition data 336, and the dump sensor data 350. 

25 As Fig. 8 shows, the FILE SYSTEM task module 224 

includes a block device function 240. The block 
device function 240 formats the media 242 of the 
storage device 204 to have N blocks, each 
addressable by a number starting from 0 and going up 

30 to but not including N (in Fig. 8, N=43) . The format 
structure includes a root node 244, which occupies 
block 0, with a redundant copy 24 4 C in block 1. The 
format structure further includes a directory node 
246, which occupies one or more blocks beginning 

35 with block 2. The format structure allocates the 
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remaining blocks, up to but not including block N, 
as space for the various data 236, 238, 336, and 350 
generated by the PROCEDURE DRIVER task module 222. 

The block device function 240 statically divides 
the remaining blocks into discrete file spaces, 
which are each allocated to accept one type of data 
236, 238, 336, or 350. Fig. 8 shows, for the purpose 
of illustration, four file spaces 248, 250, 252, and 
254, for the four types of data 236, 238, 336, and 
350, respectively. However, there are typically more 
blocks available, and additional file spaces can 
therefore be allocated. 

Each file space 248, 250, 252, and 254 comprises 
a contiguous range of blocks. In the illustrated 
embodiment (Pig. 8 ) , each file space 248, 250, 252, 
and 254 has, for the purpose of illustration, the 
same maximum size of 10 blocks. However, the data 
236, 238, 336, and 350 will impose different size 
requirements, and the file spaces 248, 250, 252, and 
254 will typically have different maximum sizes. 

a. The Root Node 
The root node 244 identifies the name of file 
system and describes the overall layout geometry 
imposed by the runtime code. The root node 244 
specifies the total capacity of the file system in 
blocks and the maximum number of fixed size files 
that may be used, i.e., how many statically 
allocated file spaces exist (which, in the 
illustrated embodiment, is four). The root node 244 
also includes a copy of the template that was used 
by the PROCEDURE DRIVER task module 222 to create 
the procedure data 236. The template is stored in 
the root node 244 principally for informational 
purposes. Still, the stored template could be used 
as a reference to reconstruct the file system, 
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allocated file spaces. 

The directory table 256 also does not indicate 
whether or not a preallocated file space contains 
data or is available. Dynamic allocation information 
is kept on the byte-stream data written to the file 
spaces, i.e., the presence or absence of data itself 
provides the allocation information for the file 
space . 

The FILE SYSTEM task module 224 as described 
retains the integrity of the block file system 
structure, despite power failure or arbitrary 
corruption of data on the storage device 204. In 
the face of such abuse, the FILE SYSTEM task module 
224 will not lose the basic block structure of the 
file system, nor will it require a distinct file 
system repair operation to be performed. Each file 
space 248, 250, 252, and 254 has a fixed maximum 
size, and the file space cannot grow to accommodate 
more data. Any allocation of file spaces 
inconsistent with the directory table 256 can be 
fixed on the fly. 

The block device function 24 0 also includes a 
hard safety check that does not allow writes to 
block numbers less than the first preallocated file 
space, once the file system has been created. The 
low-numbered blocks are only activated for writing 
during file system creation. Therefore it is 
unlikely that a software bug could destroy the 
directory blocks. Since the directory blocks are 
static, it is also unlikely they could be destroyed 
by a write error during power failure. 

c. Data Spaces 

As Fig. 10 shows, each file space 248, 250, 252, 
and 254 includes a primary node 260. The primary 
node 260 contains metadata associated with the file 
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space (i.e. allocated or free, file name, creation 
time, current size, etc.). Each file space also 
includes a secondary node 262. The secondary node 
262 has the sane contents as the primary node 260. 
This is used for "flip-flopping- while updating a 
file's metadata, as will be described later. 

Each file space 248, 250, 252, and 254 also 
includes the files »s preallocated physical space 
264. The space 264 accepts the data contents of 
allocated procedure data 236, event data 238, system 
condition data 336, or dump sensor data 350. 

The block device function 240 performs no random 
access writes. The block device function 240 allows 
either the reading and writing of whole blocks 
addressed by beginning block number, or the 
successive appending of data forward in the file 
space until the file space is filled. 

As implemented in the illustrated embodiment, at 
the outset of a given procedure, one file space 248 
is reserved for the procedure data 236 generated 
during the procedure, and one file space 250 is 
reserved for all event data 236 generated during the 
procedure. Upon the first boot-up of the data 
interface 202, one file space 252 is designated for 
system condition data 336 for all subsequent 
procedures, and one file space 254 is designated for 
dump sensor data 350 for all subsequent procedures. 
As will be described in greater detail later, the 
file spaces 252 and 254 hold ringfiles, to which the 
newest designated data 336 and 350 are appended, 
overwriting the oldest data. 

(l) The Procedure Data 
File Space 

The maximum size of the reserved procedure data 
file space 248 is selected to comfortably 


accommodate the entire template of the procedure 
data 236, plus a backup copy (as described later). 
In a representative embodiment, a maximum file size 
of about 5.6 kilobytes is reserved. 

The reserved procedure data file space 248 
receives the first procedure data 236 generated by 
the PROCEDURE DRIVER task module 222 at the outset 
of a procedure. Subsequent procedure data 236 
generated by the PROCEDURE DRIVER task module 222 
during the course of the procedure are written as a 
block to the same procedure file space 248, 
beginning at logical offset zero of the file space 
248, thereby overwriting the preceding procedure 
data in its entirety. Conceptually, the procedure 
data 236 in the file space 248 is periodically 
"refreshed" as the procedure progresses, until the 
procedure ends, which leaves the last-written 
procedure data 23 6 in the space 248, 

(2) The Event Data File 
Space 

The maximum size of the reserved event data file 
space 250 is selected to comfortably accommodate all 
event data 238 generated during a typical procedure, 
plus backup copies (as described later) . In a 
representative embodiment, a maximum file size of 
about 66.5 kilobytes is reserved. 

The reserved event data file space 250 receives 
at logical offset zero, the first event data 238 
generated by the PROCEDURE DRIVER task module 222 at 
the outset of a procedure. The next event data 238 
is appended at the end of file (EOF) point of the 
first event data 238. Successive event data 238 are 
appended in this fashion, until physical data space 
250 is filled, after which no more event data can be 
recorded for the procedure. 
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Should the data space 250 fill to its fixed 
capacity, the FILE SYSTEM task module 224 generates 
a message output to the USER INTERFACE task module 
230 (to be described later) . The assessment of the 
maximum size of the event data file space 250 should 
be carefully made, to assure that event data are not 
lost near the end of a given procedure. The block 
device function 240 can, as a back up, also include 
a function that designates a second event file 
space, should an atypical procedure occur that 
generates an atypical number of event data to fill 
the first event file space 250. 

(3) The System Condition 
Data File Space and 
the Dump Sensor File 
Space (Ringf lies) 
In like fashion, the block device function 240 
writes and successively appends system condition 
data 336 and dump sensor data 350 in the designated 
reserved file spaces, respectively, 252 and 254. 
However, unlike the file space 250, which allows no 
further data entry when its physical data space is 
filled, the block device function 240 includes a 
function 266 that accommodates continuous appending 
of system condition data 336 and dump sensor data 
350 in their respective fixed file spaces 252 and 
254. The function 266 treats the fixed physical 
allocated space 264 for these spaces 252 and 254 as 
a circular ring, or ringfile 268 (see Fig. 11) . in 
a ringfile 268, the oldest data 270 is overwritten 
with new data 272 after the file space 264 is 
filled. 

The ringfile function 266 initially appends all 
data (which, for the purpose of illustration in Fig. 
11, are system condition data 336) generated by the 
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PROCEDURE DRIVER task module 222 during a given 
procedure in the designated file space 264. As the 
data 336 are successively written to the designated 
file space 264, the size of the ringfile 268 starts 

5 at zero for the first data 336 and grows as 
additional data 336 are appended, until the file 
space 264 becomes full. At this point (see Fig. 
11) , the ringfile function 266 "wraps" the data by 
overwriting old data 270 with new data 272 beginning 

10 at the first node allocated to data in the file 
space 264 (that is, after the primary and secondary 
nodes 260 and 262, which carry the metadata). 

A ringseam 274 separates the oldest data 270 in 
the file space 264 and the newest data 272 in the 

15 file space 264. As new data 272 enters the file 

space 264, the ringseam 274 continuously moves 
toward the end of the preallocated space (as 
indicated by arrow 276 in Fig. 11) . Once the end of 
the file space 2 64 is reached, the ringseam 274 

20 wraps around to first data node and again moves 
forward toward the end of the file space 264. 

Following the first wrap of data in the file 
space 264, the ringfile function 266 maintains a 
logical ringseam pointer 278. The ringseam pointer 

25 278 marks the block address of the ringseam 274. The 
ringfile function 266 also locates the file's 
logical end-of-f ile pointer 280 at the block address 
that marks the logical junction between the newest 
data 272 and the ringseam pointer 278. The ringseam 

30 function 266 also places the logical offset zero 
pointer 282 at the block address that marks the 
logical junction between the oldest data 270 and the 
ringseam pointer 278. Following the first wrap of 
data, the ringseam function 266 appends data 

35 beginning at the logical end of file pointer 280. 
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appended. The current read or write position must 
also be updated to indicate where the next read or 
write operation should occur. 

Because the file node 260 is updated so 
frequently, and because a file node 260 is crucial 
when accessing a file, each file space 248, 250, 
252, and 254 includes the secondary file node 262. 
Each file node 260 and 262 has an "age" marker, 
which is initialized at zero when a new file is 
created in the file space. Each time the file node 
260 and 262 of the file space is modified, the file 
node's age marker is incremented. 

Whenever a file's metadata must be updated, the 
block driver function 240 registers the file node's 
age marker. if the age marker is an even number, 
the primary file node 260 is modified. Conversely, 
if the age marker is an odd number, the secondary 
file node 262 is modified. Writes to the file nodes 
260 and 262 are thereby "flip-flopped" between the 
primary and secondary file nodes 260 and 262. 

When the device block function needs to read a 
file node, it reads both primary and secondary file 
nodes 260 and 262 and considers the one with the 
highest "age" marker to be valid. This allows a 
file node update operation (i.e. a write to a file 
node) to experience a hardware failure, in which the 
entire file node is destroyed. The alternate file 
node will always contain a consistent, albeit older, 
state of the file. 

The ability to withstand abuse does not extend 
to data contained in each procedure or event data 
236 or 238. It is the responsibility of the 
PROCEDURE DRIVER task module 222 and FILE SYSTEM 
task module 224 to maintain data integrity. However, 
as a general rule, data loss will occur at the tail 


WO 99/46657 


PCT/US99/03889 


- 40 - 

of the file when it is appended in a forward 
direction. Thus, should an error occur in an append 
operation, it affects only the most recently 
appended data f which represents a relatively small 
5 portion of the overall file. 

The FILE SYSTEM task module 224 maintains file 
integrity without resort to conventional complex 
data base management functions, such as 
journalling-f ile systems, or a commit-rollback 

10 transaction facility. By not allowing formatted file 
spaces to grow, the FILE SYSTEM task module 224 
requires only small modifications to the file system 
metadata as data is written. The FILE SYSTEM task 
module 224 does not rely upon a file directory that 

15 dynamically points to where each file is located. 

The FILE SYSTEM task module 22 4 does not move blocks 
that contain file system data and then update 
pointers to refer to their new location. The FILE 
SYSTEM task module 224 does not dynamically extend 

20 the size of the file by removing blocks from a free 
pool and attaching them to the file, or dynamically 
return a file^ blocks to the free pool and 
unlinking the file from the file directory. The FILE 
SYSTEM task module 224 minimizes the windows of time 

25 during which the file system is being dynamically 
altered, and during which time a file system is 
vulnerable to catastrophic data corruption due to 
power failure. By minimizing the time of 
vulnerability, the FILE SYSTEM task module 224 

30 minimizes the chance of catastrophic corruption of 
data, should power failure occur. 

iii. The USER INTERFACE Task (File 
System Task Support) 
The USER INTERFACE task module 230 links the 

35 FILE SYSTEM task module 224 and the REPORT task 
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module 226 to the interface manager 66, which has 
been previously described. The USER INTERFACE task 
module 230 sends to the interface manager 66 
abstract Create_Display# commands prescribed to 
support the data interface 202. The interface 
manager 66 processes the data interface 202 
Create_Display# commands to generate specific 
Format_Display# commands. As before described the 
Format_Display# commands control the particular 
format, attributes, and protocols necessary to 
create, refresh, and close the visual display on the 
interface screen 60. The USER INTERFACE task module 
230 thereby provides the data interface 202 with a 
graphical user interface. 

In the illustrated embodiment (see Fig. 4), the 
Main Menu display shown by default in the working 
region 70 of the screen 60 includes a SPECIAL 
FEATURES button field 96. When touched, the SPECIAL 
FEATURES button field 96 calls up a function that 
displays a Special Features Submenu in the working 
region 70, as Fig. 6A shows. The Features Submenu 
lists in an array of touch selectable button fields 
200. one of the button fields 284 on the Special 
Features Submenu is labeled DIAGNOSTIC. 

When DIAGNOSTIC button field 284 is pushed, the 
USER INTERFACE task module 230 generates a 
prescribed Create_Display# command to the interface 
manager 66, which, in turn, generates a 
Format J>isplay# command to display a File Manger 
Submenu in the working region 70, as Fig. 6B shows. 
The File Manager Submenu lists in an array of touch 
selectable button fields 352. One of the button 
fields 354 is labeled FILESYSTEM UTILITIES. 

a. Filesystem Utilities 
When the FILESYSTEM UTILITIES button field 354 
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is pushed, the USER INTERFACE task module 230 
generates a prescribed Create_Display# command to 
the interface manager 66, which, in turn, generates 
a Forma t_Display# command to display a File System 
Information Submenu, as shown in Fig. 12. 

The File System Information Submenu includes a 
first box 286, which identifies the attributes of 
the storage device 204 of the data interface 202, 
e.g., by vendor, model, capacity, and by confirming 
its installation. This information is provided to 
the USER INTERFACE task module 230 by the FILE 
SYSTEM task module 224. The File System Information 
Submenu also includes a second box 288, which 
identifies the attributes of the FILE SYSTEM task 
module 224 itself, e.g., by identifying the software 
version of the FILE SYSTEM task module 224 which is 
installed, by confirming its operational readiness, 
and by listing its present capacity. 

The File System Information Submenu also 
includes a push button field 290 labeled FILE 
MANAGER. When the FILE MANAGER button field 290 is 
pushed, the USER INTERFACE task module 230 generates 
a prescribed Create_Display# command to the 
interface manager 66, which, in turn, generates a 
Format_Display# command to display a File Directory 
Submenu, as Fig. 13 shows. 

The File Directory Submenu includes a box field 
292. The USER INTERFACE task module 230 commands 
the FILE SYSTEM task module 224 to read the current 
metadata file node 260 or 262 of each allocated 
procedure file space 248 and event file space 250. 
The USER INTERFACE task module 230 formats the 
metadata into file system data 294, which is listed 
in rows in the box field 2 92 by E (Event Data) or P 
(Procedure Data) . suffix, time stamp, and file size 
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residing in the storage device 204. The operator can 
scroll using control buttons 296, up and down the 
rows in known fashion. 

The File Directory Submenu also includes sort- 
option push button fields 298, 300, and 3 02, 
labeled, respectively, SORT BY NAME, SORT BY DATE, 
and SORT BY SIZE. When a sort-option is selected, 
the USER INTERFACE task module 230 reformats the 
listing in the box field 292 to arrange the file 
order accordingly, by name, by date, or by size. 

The USER INTERFACE task module 230 commands the 
display of a highlight 3 04 in the File Directory 
Submenu to allow a user to select a file row. The 
File Directory Submenu includes a DELETE push button 
field 306. When the DELETE button field 306 is 
pushed, the USER INTERFACE task module 230 commands 
the FILE SYSTEM task module 224 to delete the data 
contents of the highlighted file space from the 
storage device 204. This frees the file space for 
receiving data for another procedure. 

The File Directory Submenu also includes an EXIT 
push button field 308. When the EXIT button field 
308 is pushed (or whenever the MAIN MENU button 
field 82 visible in the status region 68 is pushed), 
the USER INTERFACE task module 230 returns the 
display in the working region 70 back to the default 
Main Menu, as shown in Fig. 4. 

b. system Log Viewer 
Another button field 3 60 on the File Manager 
Submenu is labeled SYSTEM LOG VIEWER. When the 
SYSTEM LOG VIEWER button field 3 60 is pushed, the 
USER INTERFACE task module 230 generates a 
prescribed Create J>isplay# command to the interface 
manager 66, which, in turn, generates a 
Format_Display# command to display a Log Viewer 
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Submenu, as shown in Fig. 17. 

The Log Viewer Submenu includes a box field 3 62. 
The USER INTERFACE task module 230 commands the FILE 
SYSTEM task module 224 to read the system condition 
data 336 contained in the allocated ringfile space 
252. The USER INTERFACE task module 230 formats the 
system condition data 336 to display their contents 
in chronological order by row in the box field 362. 
Each row lists, e.g., a description of the state, 
condition, or error recorded, with a time stamp, and 
an identifying system reference code. Other 
information contained in the data 336 can also be 
listed. The operator can scroll using control 
buttons 3 64, up and down the rows in known fashion. 

When the MAIN MENU button field 8 2 visible in 
the status region 68 is pushed, the USER INTERFACE 
task module 230 returns the display in the working 
region 70 back to the default Main Menu, as shown in 
Fig. 4. 

c. Bar Code Display 
While the USER INTERFACE task module 230 issues 
commands to change the working region 7 0 of the 
screen 60 to display file directory information and 
functions (Figs. 12 and 13) , or the system condition 
event log (Fig. 17), the status region 68 of the 
screen 60 continues to simultaneously show its 
information. The MINOR MODE field 76 continues to 
show that the procedure is in the collection mode, 
and the status region continuously shows in the WB 
PROCESSED FIELD 78 the volume of WB drawn from the 
donor. The location and attributes of the other 
button fields 80/82/84/86 remain unchanged, unless 
the procedure changes operational mode, at which 
time the MINOR MODE field 7 6 will change to reflect 
this mode change. 
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The USER INTERFACE task module 23 0 also 
communicates with the BAR CODE task module 220. The 
USER INTERFACE task module 230 receives the feedback 
message 232 generated by the BAR CODE task module 
5 220 upon confirming acceptance of bar code-scanned 

input (see Fig. 7). As Figs. 12, 13, and 20 show, 
the USER INTERFACE task module 23 0 commands the 
display of the feedback message in the a BAR CODE 
field 3 58 provided in the status region 68 of the 
10 screen 60. 

iv. The REPORT task 
The REPORT task module 22 6 communicates with the 
printer port link 212. The REPORT task module 226 
is serviced by the FILE SYSTEM task module 224 and 

15 the USER INTERFACE task module 230. When active, the 

REPORT task module 226 directs the FILE SYSTEM task 
module 224 to locate and read designated procedure 
and event data 236 and 23 8 then-residing in the 
storage device 204. The REPORT task module 226 

20 builds reports presenting the data in prescribed 

alpha-numeric format, which Figs. 14 and 15 
exemplify. The REPORT task module 22 6 downloads the 
report to the printer 216. 

The format and contents of printed reports can, 

25 of course, vary. For example, the REPORT task module 
226 can generate a Procedure Report 310 (see Fig. 
14), which is built upon a procedure data 236 
contained in a given procedure data file space 248 
on the storage device 204. As another example, the 

30 REPORT task module 22 6 can generate an Event Report 
312 (see Fig. 15), which lists in time order the 
contents of the event data stored in a given event 
data file space 250 on the storage device 204. 

V. The USER INTERFACE Task (REPORT 

35 Task Support) 


WO 99/46657 PCT/US99/03889 

- 46 - 

The USER INTERFACE task module 230 also links 
the REPORT task nodule 226 to the interface manager 
66. In the illustrated embodiment, one of the button 
fields 314 on the Special Features Submenu (see Fig. 
5 6A) (which is accessed through SPECIAL FEATURES 

button field 96 on the Main Menu display, shown in 
Fig. 4) is labeled PRINT PROCEDURE REPORTS. When the 
PRINT PROCEDURE REPORTS button field 314 is pushed, 
the USER INTERFACE task module 230 generates a 
10 prescribed Create_Display# command to the interface 
manager 66, which, in turn, generates a 
Format_Display# command to display a Print Procedure 
Reports Submenu, shown in Fig. 16. 

The Print Procedure Reports includes a box field 
15 316, which lists by row the procedures for which 
current procedure and event data 236 and 238 reside 
on the storage device 204. The operator can scroll 
using control buttons 318, up and down the rows in 
known fashion. The USER INTERFACE task module 230 
20 displays a highlight 320 to make a selection. 

The Print Procedure Reports Submenu includes a 
PRINT SELECTED REPORT push button field 322. When 
pushed, the USER INTERFACE task module 23 0 commands 
the REPORT task module 226 to format and print the 
25 formatted reports for the selected procedure (which, 
in the illustrated embodiment, are the Procedure 
Report 310 shown in Fig. 14 and the Event Report 312 
shown in Fig. 15. By selected a CANCEL CURRENT 
REPORT push button 324 field, the user can terminate 
30 printing of the selected reports. 

The Print Procedure Reports Submenu also 
includes a Printer Status box field 326. The Printer 
Status box field 326 displays information from the 
COMMUNICATION MANAGER task module 218 that reports 
35 status of the printer 216, e.g., Idle, Busy, Error. 
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When the MAIN MENU button field 82 visible in 
the status region 68 is pushed, the USER INTERFACE 
task module 230 returns the display in the working 
region 70 back to the default Main Menu, as shown in 
Fig. 4. 

The USER INTERFACE task module 230 also allows 
the operator to condition the REPORT task module 226 
to automatically compile and print the Procedure 
Report 310 and Event Report 312 at the conclusion of 
a procedure. In the illustrated embodiment (see 
p ig- 6A) , one of the button fields 330 on the 
Features Submenu is labeled SYSTEM CONFIGURATION. 
When the SYSTEM CONFIGURATION button field 330 is 
pushed, the USER INTERFACE task module 230 generates 
a prescribed Create_Display# command to the 
interface manager 66, which, in turn, generates a 
Format_Display# command to display a System 
Configuration Submenu, as shown in Fig. 18. The 
System Configuration Submenu, in turn, includes a 
SET CONFIGURATION button 332, which, when pushed, 
causes the display of a Set Configuration Submenu, 
as shown in Fig. 19. The Set Configuration Submenu 
includes an "AutoPrint" push button field 334. 
Pushing the button 334 toggles the button label 
between Turn On and Turn Off. 

When toggled to the Turn Off state (in which the 
autoprint feature is actuated) , the data interface 
202 is conditioned to automatically compile and 
print the Procedure Report 310 and Event Report 312 
at the end of the procedure. 

D. The DATA EXCHANGE task 

I. Data Transfer Function 

It should be appreciated that, due to the 
features of the PROCEDURE DRIVER task module 222, 
the FILE SYSTEM task module 224, the PRINT task 
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module, and the USER INTERFACE task module 230 
already described, the data interface 202 is fully 
integrated to store, retrieve, and manipulate data 
without the use of or connection to an external 
computer 206. 

However, the second port 210 makes it possible, 
if desired, to link the data interface 202 to an 
external computer 206, The DATA EXCHANGE task module 
228 includes a data share function 384, which 
establishes a communication exchange interface 
between the on-board data interface 202 and the 
external computer 206. 

In one embodiment, the external computer 206 
coupled to the second port link 210 can include its 
own resident control software 338 (see Fig. 7). The 
software 338 is programmed to prompt the data 
interface 202 for key control and processing 
parameters of a given procedure. The data share 
function 384 of the DATA EXCHANGE task module 228 
responds by assembling and downloading this data to 
the computer 206 for storage, retrieval, or 
manipulation. 

In this arrangement, the data share function 384 
of the DATA EXCHANGE task module 228 generates a 
random access data file 340, designated 
Act2_Proc_Data in Fig. 7. Act2_Proc_Data file 340 
is formatted the same as the Act_Proc_Data file 234 
maintained in random access memory by the PROCEDURE 
DRIVER task module 222. While a given procedure is 
underway, the data share function 384 periodically 
copies data from the Act_Proc_Data file 234 into the 
Act2_Proc_Data file 34 0. While a given procedure is 
underway, the data share function 384 can also 
periodically read event data residing in the current 
event data file space 250 on the storage device 204. 
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However, while a given procedure is underway, the 
data share function 384 can not read the current 
procedure data file space 248 on the storage device 
204. 

The control software 338 residing in the 
external computer 206 sends programmed ASCII input 
to the data share function 384 as the procedure 
progresses, m response to the programmed input, the 
data share function 384 builds desired responses 
based upon data read from the Act2_Proc_Data file 
340 or from the current event data file space 250 on 
the storage device 204. The data share function 384 
transmits the responses to the external computer 206 
for storage, retrieval, or manipulation. Once a 
procedure is completed, the data share function 384 
can read data from both the procedure data file 
space 248 and the event data file space 250 on the 
storage device 204, to build responses to 
preprogrammed input from the external computer 2 06. 

In the illustrated embodiment, the data share 
function 384 is automatically activated whenever the 
COMMUNICATION MANAGER task module 218 senses 
communication through the port 210 with a computer 
206 having the enabling control software 338. 
25 ii. control input Function 

The DATA EXCHANGE task module 228 also includes 
a data control function 386, by which process 
control input 388 can be received from the external 
computer 206. in this arrangement, the control 
software 338 of the computer 206 establishes on the 
computer 206 a graphical user interface compatible 
with the interface manager 66. The data control 
function 386 transmits the process control input 388 
from computer 206 to the interface manager 66, via 
35 the USER INTERFACE task module 230. The process 


20 


30 
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control input 388 serves the same command and 
control functions as corresponding input from the 
screen 60, as previously described. 

The data control function 386 makes it possible 
5 to establish or alter processing parameters for the 
controller 18 from a remote location. 

iii. Purge Function 
In the illustrated embodiment, the DATA EXCHANGE 
task module 228 includes a PURGE function 344. The 

10 PURGE function 344 performs house-keeping on the 
number of files managed by the FILE SYSTEM task 
module 224. At prescribed intervals (e.g., at the 
conclusion or each procedure) , the PURGE function 
344 reads the metadata file nodes 260/262 maintained 

15 by the FILE SYSTEM task module 224. The PURGE 

function directs the FILE SYSTEM task module 224 to 
delete data from the procedure and event data file 
spaces in excess of a prescribed number according to 
where the oldest data exists. For example, if the 

20 FILE SYSTEM task module 224 has allocated file space 
for forty (40) procedures (i.e., forty procedure 
data file spaces and forty event data file spaces) , 
the PURGE function 314 deletes the data in allocated 
procedure and event file spaces in excess of thirty 

25 (30) each, according to where the oldest data are 

stored. In this way, the data interface 202 
maintains current procedure and event data 23 6 and 
238 for the thirty (3 0) most recent procedures. The 
ringfile nature of the system condition data 336 and 

30 dump sensor data 350 automatically assures that only 
recent data is maintained. 

In a representative implementation, the storage 
device 204 has eight megabytes of storage space. 
The block device function 24 0 allocates two files 

35 spaces of 100 kilobytes each, one for the system 
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condition data file space 252 and the other being an 
open extra file space. The block device function 
240 also allocates two files spaces of l megabyte 
each, one for the dump sensor data file space 254 
5 and the other being an open extra file space. The 
block device function 240 further allocates 70 file 
spaces of 5.6 kilobytes each as procedure data file 
spaces 248, and 70 file spaces of 66.5 kilobytes 
each as event data file spaces 250. Controlled by 
10 the purge function 314, thirty each of these file 
spaces 248 and 250 hold the current procedure data. 
The remaining thirty are free file spaces. 

E. The USER INTERFACE Task (Data Exchange 
Task Support) 
15 i- File Transfer Function 

In another embodiment, procedure or event data 
files residing on the storage device 204 can be 
transferred, or downloaded, in any arbitrary order 
to any compatible external computer 206 linked to 
20 the second port, as controlled by the USER INTERFACE 
task module 230 of the data interface 202, and 
without otherwise requiring control software on the 
external computer 206. 

As implemented in the illustrated embodiment, 
25 the File Directory Submenu (see Fig. 13) includes a 
TRANSFER push button field 346. When the TRANSFER 
button field 346 is pushed, the USER INTERFACE task 
module 230 commands the FILE SYSTEM task module 224 
to copy data in the highlighted file from the 
30 storage device 204 to the DATA EXCHANGE task module 
228. The DATA EXCHANGE task module 228, in turn, 
transfers the data to the external computer 206 via 
the second port. The external computer 206 can 
store, retrieve, and manipulate the data using on- 
35 board data processing software. 
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The integrated data recording function of the 
data interface 202 does not require an external 
computer 206 connected during the data storage 
process. Furthermore, any external computer 206 may 
be connected after the data has been stored by the 
data interface 202. The data interface 202 also 
makes possible to download data to an external 
computer 206 at an arbitrary time and in an 
arbitrary fashion after the processing function has 
been completed. Data collected by the data 
interface 202 is also available to field service 
personnel, which allows accurate program diagnosis 
and instrument performance evaluation. 

ii. File Import Function 

In the illustrated embodiment (see Fig. 21), the 
DATA EXCHANGE task module 228 includes an import 
function 380. The import function 380 permits the 
import, or uploading, of additional operating 
algorithms 382 from the external computer 206 into 
the controller 18 for implementation. 

In the illustrated implementation, the System 
Configuration Submenu (Fig. 18) includes a IMPORT 
CONFIGURATION button 378, which, when pushed, 
activates an import function 380. The import 
function 3 80 boots the MPU 44 of the controller 18 
into an import mode, which is governed by the 
control software 338 of the computer 206 coupled to 
the port link 210. Governed by input from the 
computer 206, the control software 3 38 installs one 
or more additional operating algorithms 382 as 
process software in EPROM's in the MPU 44, and, in 
particular, the instrument control manager 46, the 
instrument manager 50, and the interface manager 66. 

The imported algorithms 382 establish one or 
more new applications that can be called up by the 
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application control manager 46. The imported 
algorithms also install implementing process 
software in the instrument manager 50 and interface 
manager 66. 
5 P. The DATA DUMP Task 

In the illustrated embodiment, the user 
interface 202 also includes a DATA DUMP task module 
366. The DATA DUMP task module 3 66 communicates 
with the port link 34 8 and the FILE SYSTEM task 

10 module 224. The DATA DUMP task function 366 

periodically reads the data contents of the file 
space (i.e., space 254 in Fig. 8), where the FILE 
SYSTEM task module 24 4 writes the dump sensor data 
350. The DATA DUMP task module 366 formats the 

15 current dump sensor data 350 as a message buffer 

output 370, which is transmitted through the port 
link 348 to a connected external computer 206*. 

The external computer 206 1 includes enabling 
control software 368. The software 368 conditions 

20 the computer 206' to receive the formatted message 
buffer output 370 for storage, retrieval, or 
manipulation. 

For example, the DATA DUMP task module 366 can 
automatically assemble and transmit a message buffer 

25 output 370 every five seconds to the port link 348, 
for download to the external computer 206 1 . This 
time-sequential record, maintained by the external 
computer 206 1 provides an accurate, comprehensive 
account of sensed conditions throughout the 

30 procedure. This record can be used by service or 
diagnostic technicians to troubleshoot system 
errors. This record can also aid research and 
development technicians in designing, developing, 
and implementing new operating algorithms for the 

35 application control manager 46. 


In Fig. 20, the DATA DUMP task nodule 366 
includes a predictor function 372. The predictor 
function 372 includes algorithms which analyze the 
contents of successive message buffer outputs 370 
according to predetermined criteria. For example, 
the criteria can gauge sensed conditions with 
respect to compliance with established operating 
ranges. The criteria can assess changes in sensed 
conditions over time, using proportional, integral, 
or derivative analyses, or combinations thereof. 
The criteria can compare the sensed conditions with 
respect to other empirically developed standards or 
test algorithms, using, for example, correlation or 
fuzzy logic techniques. 

On the basis of its analyses, the predictor 
function 372 generates diagnostic output files 374. 
The diagnostic output files 374 indicate system 
performance trends and predict potential system 
errors or failures before they occur. 

The output files 374 are managed by the FILE 
SYSTEM task module 224 in the same manner as, for 
example, the system condition data files 336, for 
viewing through the USER INTERFACE task module 230 
with the system condition data files 336. Fig. 17 
shows the inclusion of a diagnostic notice 376 based 
upon a diagnostic output file 374, which identifies 
an adverse performance trend and recommends a 
service check before failure occurs. Alternatively, 
or in combination, the contents of a diagnostic 
output file 374 could be included as an item in the 
Event Report 312, handled through the REPORT task 
module 226. 

Alternatively, or in combination, the enabling 
control software 368 of the external computer 206' 
can incorporate the predictor function 372. m this 
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arrangement, the external computer 206' can provide 
its own diagnostic notice 376 in visual or hard copy 
torn . J 

The data interface 202 and graphical interface 
as described can be realized, e.g., as a " C « 
language program implemented using the MS WINDOWS™ 
application and the standard WINDOWS 32 API 
controls, e.g., as provided by the WINDOWS™ 
Development Kit, along with conventional graphics 
software disclosed in public literature. 

Various features of the invention are set forth 
in the following claims. 
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Wft Claim 

1. A blood processing system comprising 
a device including processing hardware to 

carry out a blood processing procedure, 

a processing manager residing on the device 
5 to monitor status conditions during the blood 

processing procedure, and 

a data interface residing on the device 

including a data generator task to generate data 

based upon monitored status conditions, a flash 
0 memory data storage medium, and a file manager task 

to write the data to the flash memory data storage 

medium. 

2. A system according to claim 1 
wherein the flash memory data storage 

medium includes a block file space, to which the 
data is written by the file manager task. 

3. A system according to claim 2 
wherein the file manager task appends the 

data to the block file space. 

4. A system according to claim 2 
wherein the file manager task overwrites 

old data in the block file space with new data. 

5. A system according to claim 2 
wherein the block file space has a fixed 

maximum size. 

6. A system according to claim 5 
wherein the file manager task appends the 

data to the block file space until the fixed maximum 
size is reached. 

7. A system according to claim 6 
wherein the file manager task generates an 

output when the fixed maximum size is reached. 

8. A system according to claim 5 
wherein, when the fixed maximum size is 
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exceeded, the file manager task appends the data to 
the block file space by overwriting oldest data with 
newest data. 

9. A system according to claim i 
wherein the data interface includes a print 

task coupled to the file manager task to print data 
written to the flash memory storage medium. 

10. A system according to claim 1 
wherein the data interface includes a view 

task coupled to the file manager task to view data 
written to the flash memory storage medium. 

11. A system according to claim 1 
wherein the data interface includes an 

exchange task coupled to the file manager task to 
offload data from the flash memory storage medium. 

12. A system according to claim 1 
wherein the data interface includes a 

system task coupled to the file manager task for 
manipulating data written to the flash memory 
storage medium. 

13. A system according to claim l 
wherein the flash memory data storage 

medium includes a block file space, to which the 
data is written by the file manager task, the block 
file space including a node to record metadata for 
the block file space. 

14. A system according to claim 13 
wherein the data interface includes a 

system task for viewing the metadata. 

15. A blood processing system comprising 
means for monitoring status conditions over 

time during a blood processing procedure, 

means for generating data based upon 

monitored status conditions, and 

means for writing the data to a flash 


memory storage medium. 

16. A system according to claim 15 

and further including means for 
manipulating the data written to the flash memory 
storage medium. 

17. A system according to claim 15 

and further including means for retrieving 
the data written to the flash memory storage medium. 

18. A blood processing system comprising 
a device including processing hardware to 

carry out a blood processing procedure, 

a processing control manager residing on 

the device to monitor status conditions during the 

blood processing procedure , 

a data interface residing on the device 

including 

a data storage medium having first and 
second block file spaces to receive data, 

a data generator task to generate 
discrete first and second data streams based upon 
status conditions monitored over time, and 

a file manager task to append each 
first data stream chronologically to the first block 
file space and to overwrite each second data stream 
in succession in the second block file space. 

19. A system according to claim 18 
wherein the data interface includes a print 

task element coupled to the file manager task to 
compile data in at least one of the block files for 
printing. 

20. A system according to claim 19 
wherein the print task formats the complied 

data for printing as a prescribed report. 

21. A system according to claim 18 
wherein the data interface includes a view 
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task coupled to the file manager task to compile 
data in at least one of the block files for viewing. 

22. A system according to claim 18 
wherein the data interface includes an 

exchange task coupled to the file manager task to 
offload data from at least one of the block files. 

23. A system according to claim 18 
wherein the data interface includes a 

system task coupled to the file manager task for 
manipulating data written to at least one of the 
block files. 

24. A system according to claim 18 
wherein the first block file has a fixed 

maximum size, and 

wherein the file manager task appends the 
first data streams chronologically to the first 
block file space until the fixed maximum size is 
reached. 

25. A system according to claim 24 
wherein the file manager task generates an 

output when the fixed maximum size is reached. 

26. A system according to claim 18 
wherein the first block file has a fixed 

maximum size, and 

wherein, when the fixed maximum size is 
exceeded, the file manager task appends by 
overwriting oldest first data streams with newest 
first data streams. 

27. A system according to claim 18 
wherein both the first and second block 

file spaces have fixed maximum sizes. 

28. A system according to claim 18 
wherein the data storage medium comprises 

a flash memory storage device. 

29. A blood processing system comprising 
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a device including processing hardware to 
carry out a blood processing procedure, 

a processing control manager on the device 
coupled to the processing hardware to monitor status 
conditions over time during the blood processing 
procedure, and 

a data interface on the device coupled to 
the processing control manager including 

a data storage medium including a file 
space formatted to a fixed maximum size, 

a data generator task to generate 
chronologic data streams based upon status 
conditions monitored over time, and 

a file manager task to append the 
chronologic data streams to the file space in 
chronologic order and to read the chronologic data 
streams from the file space as a chronologic block 
file. 

30. A system according to claim 29 
wherein the data interface includes a print 

task coupled to the file manager task to compile 
data in the chronologic block file for printing. 

31. A system according to claim 29 
wherein the data interface includes a view 

task coupled to the file manager task to compile 
data in the chronologic block file for viewing. 

32. A system according to claim 29 
wherein the file manager task appends 

chronologic data streams to the file space until the 
fixed maximum size is reached. 

33. A system according to claim 32 
wherein the file manager task generates an 

output when the fixed maximum size is reached. 

34. A system according to claim 29 
wherein the file manager task appends 
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chronologic data streams to the file space by 
overwriting oldest data streams with newest data 
streams . 

35. a system according to claim 29 
wherein the data storage medium comprises 

a flash memory storage device. 

36. A blood processing system comprising 
a device including processing hardware to 

carry out a blood processing procedure, 

a processing control manager on the device 
coupled to the processing hardware to monitor status 
conditions over time during the blood processing 
procedure, and 

a data interface on the device coupled to 
the processing control manager including 

a data storage medium including a file 
space formatted to a fixed maximum size, 

a data generator task to generate a 
time-specific data stream based upon status 
conditions at a point in time, and 

a file manager task to write the time- 
specific data stream to the file space as a time- 
specific block file and to read the time-specific 
data stream from the file space as the time-specific 
block file. 

37. A system according to claim 36 
wherein the data interface includes a print 

task coupled to the file manager task to compile 
data in the time-specific block file for printing. 

38. A system according to claim 36 
wherein the data storage medium comprises 

a flash memory storage device. 

39. A blood processing system comprising 
a device including processing hardware to 

carry out a blood processing procedure, 
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a processing control manager on the device 
coupled to the processing hardware to monitor status 
conditions over time during the blood processing 
procedure, and 

a data interface on the device coupled to 
the processing control manager including 

a data storage medium including a 
first file space formatted to a fixed maximum size 
and a second file space formatted to a fixed maximum 
size, 

a data generator task to generate 
chronologic data streams based upon status 
conditions monitored over time and to generate a 
time-specific data stream, based upon status 
conditions at a point in time, and 

a file manager task to append the 
chronologic data streams in chronologic order to the 
first file space and not the second file space and 
to write the time-specific data stream to the second 
file space and not the first file space as a time- 
specific block file. 

40. A system according to claim 39 
wherein the data storage medium comprises 

a flash memory storage device. 

41. A method for processing data during a 
blood processing procedure comprising the steps of 

monitoring status conditions over time 
during the blood processing procedure, 

generating data based upon monitored status 
conditions, and 

writing the data to a flash memory storage 

medium. 

42. A method according to claim 41 

and further including the step of 
manipulating the data written to the flash memory 
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storage medium. 

43. A method according to claim 41 

and further including the step of 
retrieving the data written to the flash memory 
storage medium. 

44. A method for processing data during a 
blood processing procedure comprising the steps of 

monitoring status conditions over time 
during the blood processing procedure, 

generating a succession of first and second 
data streams based upon monitored status conditions , 
and 

writing the first and second data streams 
to a storage medium having allocated first and 
second block file spaces, by appending each first 
data stream in chronological order only to the first 
block file space and by overwriting each second data 
stream in succession only to the second block file 
space, to thereby maintain during the procedure a 
chronologic block file in the first block file space 
and a time-specific block file in the second block 
file space. 

45. A method according to claim 44 

and further including the step of 
manipulating the data written to at least one of the 
block file spaces. 

46. A method according to claim 44 

and further including the step of 
retrieving the data written to at least one of the 
block file spaces. 

47. A method according to claim 44 
wherein the writing step includes writing 

the first and second data streams to a flash memory 
storage medium. 
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PROCEDURE REPORT 
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DONOR DATA 
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Kit Expiration Date : 

PROCEDURE RESULTS 

ACD Used : 

Saline Used : 

ACD in Plama Product 

ACD in Storage Plasma : 

Collection Time 

Whole Blood Processed : 

Total Whole Blood Drawn : 

Plasma Product Volume : 

Storage Plasma Volume : 

Total Warning Alarms ; 
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Mode; Enter Parameters 

WB to Process (ml): 0 -*300 

<5 0 ml WB Processed 

WB to Process (ml): 300 -^3000 
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Mode: Procedure Setup 

Start Needle Prime® 16:57:07 hrs 
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